Message Delivery System and Method

ABSTRACT

The disclosed systems and methods include receiving a message by a communication client, where the message includes a trigger event that is to occur for a condition to be checked, and the condition includes a parameter value for evaluating whether the condition has been satisfied. The systems and methods further include monitoring a user terminal subsequent to receiving the message to determine whether the trigger event occurs at the user terminal in addition, the disclosed systems and methods determine whether the condition has been satisfied at the user terminal in response to a determination that the trigger event occurred, and display a selectable option for reconfiguring an attribute of the communication client in response to a determination that the condition has been satisfied. The disclosed systems and methods also include reconfiguring the attribute of the communication client in response to a selection of the selectable option,

RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 15/692,896, titled “Message Delivery System andMethod” and filed Aug. 31, 2017, which is a continuation of U.S. Pat.No. 9,756,004, filed Nov. 8, 2007 and titled “Message Delivery Systemand Method,” the disclosures of which are incorporated by referenceherein in their entireties.

TECHNICAL FIELD

This invention relates to a message delivery system and method,particularly but not exclusively for use in a packet-based communicationsystem.

BACKGROUND

Packet-based communication systems allow the user of a device, such as apersonal computer, to communicate across a computer network such as theInternet. Packet-based communications systems include voice overinternet protocol (“VoIP”) communication systems and instant messaging(“IM”) systems. These systems are beneficial to the user as they areoften of significantly lower cost than fixed line or mobile networks.This may particularly be the case for long-distance communication. Touse a VoIP or IM system, the user must install and execute clientsoftware on their device. The client software provides the VoIP or IMconnections as well as other functions such as registration andauthentication. In addition to voice communication, the client may alsoprovide further features such as video calling.

One type of packet-based communication system uses a peer-to-peer(“P2P”) topology built on proprietary protocols. To enable access to apeer-to-peer system, the user must execute P2P client software providedby a P2P software provider on their computer, and register with the P2Psystem. When the user registers with the P2P system the client softwareis provided with a digital certificate from a server. Once the clientsoftware has been provided with the certificate, communication cansubsequently be set up and routed between users of the P2P systemwithout the further use of a server. In particular, the users canestablish their own communication routes through the P2P system based onthe exchange of one or more digital certificates(or user identitycertificates, “UIC”), which enable access to the P2P system. Theexchange of the digital certificates between users provides proof of theuser's identities and that they are suitably authorised andauthenticated in the P2P system. Therefore, the presentation of digitalcertificates provides trust in the identity of the user. It is thereforea characteristic of peer-to-peer communication that the communication isnot routed using a server but directly from end-user to end-user.Further details on such a P2P system are disclosed in WO 2005/009019.

In contrast to traditional communication systems such as fixed-line ormobile networks, the communication client for a packet-basedcommunication client has a flexible, rich graphical user interface. Thegraphical user interface is displayed to the user on a display of thepersonal computer, and permits the communication client to present alarge number of features and options to the user. However, it isdifficult for the provider of the client software to inform the user ofthese features in a timely and non-intrusive manner.

SUMMARY

This disclosure describes a method that includes receiving a message bya communication client, the message comprising a trigger event that isto occur for a condition to be checked, the condition comprising aparameter value for evaluating whether the condition has been satisfied,monitoring a user terminal subsequent to receiving the message todetermine whether the trigger event occurs at the user terminal, anddetermining whether the condition has been satisfied at the userterminal in response to a determination that the trigger event occurred.The method also includes displaying a selectable option forreconfiguring an attribute of the communication client in response to adetermination that the condition has been satisfied, and reconfiguringthe attribute of the communication client in response to a selection ofthe selectable option.

In another embodiment of the method, the method includes reading acurrent value of a parameter in the user terminal and comparing thecurrent value to the parameter value of the condition.

In a further embodiment of the method, the parameter value defines amaximum number of times the message is to be displayed by thecommunication client.

In yet another embodiment of the method, the parameter value defines astart time and an end time for displaying the message.

In yet a further embodiment of the method, the method includestransmitting, prior to the receiving, a request for the message over acommunication network.

In another embodiment of the method, the request for the messagecomprises an identifier of a plurality of messages stored at the userterminal.

In a further embodiment of the method, the request for messagescomprises at least one of a version number for a communication clientexecuted on the user terminal and an identifier of an operating systemexecuted on the user terminal.

In yet another embodiment of the method, the message is received at theuser terminal in a bundle comprising a plurality of messages.

In yet a further embodiment of the method, the method includesdisplaying a selectable control configured to cause display ofinformation included with the message.

In another embodiment of the method, the selectable control is ahyperlink comprising a network address of the information.

This disclosure further describes a system that includes one or moreprocessors, and one or more computer-readable storage devices havingcomputer-executable instructions stored thereon that, when executed bythe one or more processors, configure a user terminal to perform aplurality of operations comprising receiving a message by acommunication client, the message comprising a trigger event that is tooccur for a condition to be checked, the condition comprising aparameter value for evaluating whether the condition has been satisfied,and monitoring the user terminal subsequent to receiving the message todetermine whether the trigger event occurs at the user terminal. Theplurality of operations further comprises determining whether thecondition has been satisfied at the user terminal in response to adetermination that the trigger event occurred, displaying a selectableoption for reconfiguring an attribute of the communication client inresponse to a determination that the condition has been satisfied, andreconfiguring the attribute of the communication client in response to aselection of the selectable option.

In another embodiment of the system, the plurality of operations furthercomprises reading a current value of a parameter in the user terminaland comparing the current value to the parameter value of the condition.

In a further embodiment of the system, the parameter value defines amaximum number of times the message is to be displayed by thecommunication client.

In yet another embodiment of the system, the parameter value defines astart time and an end time for displaying the message.

In yet a further embodiment of the system, the plurality of operationsfurther comprises transmitting, prior to the receiving, a request forthe message over a communication network.

In another embodiment of the system, the request for the messagecomprises an identifier of a plurality of messages stored at the userterminal.

In a further embodiment of the system, the request for messagescomprises at least one of a version number for a communication clientexecuted on the user terminal and an identifier of an operating systemexecuted on the user terminal.

In yet another embodiment of the system, the message is received at theuser terminal in a bundle comprising a plurality of messages.

In yet a further embodiment of the system, the plurality of operationsfurther comprises displaying a selectable control configured to causedisplay of information included with the message.

In another embodiment of the system, the selectable control is ahyperlink comprising a network address of the information.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to show how thesame may be put into effect, reference will now be made, by way ofexample, to the following drawings in which:

FIG. 1 shows a P2P communication system.

FIG. 2 shows an example user interface of a client.

FIG. 3 shows a detailed view of a user terminal.

FIG. 4 shows a flowchart for defining and publishing a message.

FIG. 5 shows the structure of a message,

FIG. 6 shows the process for a client to fetch a message.

FIG. 7 shows a flowchart for a client to display a message.

FIG. 8 shows a message display region in a contact tab of a client.

FIG. 9 shows a message display region in a dial tab of a client.

FIG. 10 shows a message display region in a public conversations tab ofa client

FIG. 11 shows a message display region in a directory tab of a client.

FIG. 12 shows a message display region displayed during a call.

FIG. 13 shows example messages displayed in the client.

DETAILED DESCRIPTION

Reference is first made to FIG. 1, which illustrates a P2P communicationsystem 100. Note that whilst this illustrative embodiment is describedwith reference to a P2P communication system, other types ofcommunication system could also be used, such as instant messagingsystems and other, non-P2P, VoIP systems. A first user of the P2Pcommunication system (denoted “User A” 102) operates a user terminal104, which is shown connected to a P2P network 106. Note that the P2Pnetwork 106 utilises a communication system such as the Internet, but isillustrated as a separate network in FIG. 1 for clarity. The userterminal 104 may be, for example, a personal computer (“PC”), personaldigital assistant (“PDA”), a mobile phone, a gaming device or otherembedded device able to connect to the P2P network 106. The user deviceis arranged to receive information from and output information to a userof the device. In a preferred embodiment of the invention the userdevice comprises a display such as a screen and a keyboard and mouse.The user device 104 is connected to the P2P network 106 via a networkinterface 108 such as a modem, and the connection between the userterminal 104 and the network interface 108 may be via a cable (wired)connection or a wireless connection.

The user terminal 104 is running a client 110, provided by the P2Psoftware provider. The client 110 is a software program executed on alocal processor in the user terminal 104. The user terminal 104 is alsoconnected to a handset 112, which comprises a speaker and microphone toenable the user to listen and speak in a voice call. The microphone andspeaker does not necessarily have to be in the form of a traditionaltelephone handset, but can be in the form of a headphone or earphonewith an integrated microphone, or as a separate loudspeaker andmicrophone independently connected to the user terminal 104.

An example of a user interface 200 of the client 110 executed on theuser terminal 104 of User A 102 is shown illustrated in FIG. 2. Theclient user interface 200 displays the username 202 of User A 102 in theP2P system, and User A can set his own presence state (that will be seenby other users) using a drop down list by selecting icon 204.

The client user interface 200 comprises a tab 206 labelled “contacts”,and when this tab is selected the contacts stored by the user in acontact list are displayed. In the example user interface in FIG. 2,five contacts of other users of the P2P system (User B to F) are shownlisted in contact list 208. Each of these contacts have authorised theuser of the client 110 to view their contact details and online presenceand mood message information. Each contact in the contact list has apresence status icon associated with it. For example, the presencestatus icon for User B 210 indicates that User B is “online”, thepresence icon for User C 212 indicates that User C is “not available”,the presence icon for User D 214 indicates that User D's state is “donot disturb”, the presence icon for User E 216 indicates User E is“away”, and the presence icon for User F 218 indicates that User F is“offline”. Further presence indications can also be included. Next tothe names of the contacts in pane 208 are the mood messages 220 of thecontacts.

The contact list for the users (e.g. the contact list 208 for User A) isstored in a contact server (not shown in FIG. 1). When the client 110first logs into the P2P system the contact server is contacted, and thecontact list is downloaded to the user terminal 104. This allows theuser to log into the P2P system from any terminal and still access thesame contact list. The contact server is also used to store the user'sown mood message (e.g. the mood message of User A 102) and a pictureselected to represent the user (known as an avatar). This informationcan be downloaded to the client 110, and allows this information toconsistent for the user when logging on from different terminals. Theclient 110 also periodically communicates with the contact server inorder to obtain any changes to the information on the contacts in thecontact list, or to update the stored contact list with any new contactsthat have been added. Presence information is not stored centrally inthe contact server. Rather, the client 110 periodically requests thepresence information for each of the contacts in the contact list 208directly over the P2P system. Similarly, the current mood message foreach of the contacts, as well as a picture (avatar) that has been chosento represent the contact, are also retrieved by the client 110 directlyfrom the respective clients of each of the contacts over the P2P system.

Calls to the P2P users in the contact list may be initiated over the P2Psystem by selecting the contact and clicking on a “call” button 222using a pointing device such as a mouse. Alternatively, the call may beinitiated by typing in the P2P identity of a contact in the field 224.Referring again to FIG. 1, the call set-up is performed usingproprietary protocols, and the route over the network 106 between thecalling user and called user is determined by the peer-to-peer systemwithout the use of servers. In FIG. 1, an illustrative route is shownbetween the caller User A (102) and the called party, User B (114), viaother peers (116, 118, 120) of the P2P system. It will be understoodthat this route is merely an example, and that the call may be routedvia fewer or more peers.

Following authentication through the presentation of digitalcertificates (to prove that the users are genuine subscribers of the P2Psystem—described in more detail in WO 2005/009019), the call can be madeusing VoIP. The client 110 performs the encoding and decoding of VoIPpackets. VoIP packets from the user terminal 104 are transmitted intothe network 106 via the network interface 108, and routed to thecomputer terminal 122 of User B 114, via a network interface 123. Aclient 124 (similar to the client 110) running on the user terminal 122of User B 114 decodes the VoIP packets to produce an audio signal thatcan be heard by User B using the handset 126. Conversely, when User B114 talks into handset 126, the client 124 executed on user terminal 122encodes the audio signals into VoIP packets and transmits them acrossthe network 106 to the user terminal 104. The client 110 executed onuser terminal 104 decodes the VoIP packets from User B 114, and producesan audio signal that can be heard by the user of the handset 112.

The VoIP packets for calls between P2P users (such as 102 and 114) asdescribed above are passed across the network 106 only, and the PSTNnetwork is not involved. Furthermore, due to the P2P nature of thesystem, the actual voice calls between users of the P2P system can bemade with no central servers being used. This has the advantages thatthe network scales easily and maintains a high voice quality, and thecall can be made free to the users. Additionally, calls can also be madefrom the client (110, 122) using the P2P system to fixed-line or mobiletelephones, by routing the call via a gateway 128 to the PSTN network130. Similarly, calls from fixed-line or mobile telephones can be madeto the P2P system via the PSTN 130 and gateway 128.

FIG. 3 illustrates a detailed view of the user terminal (104) on whichis executed client 110. The user terminal 104 comprises a centralprocessing unit (“CPU”) 302, to which is connected a display 304 such asa screen, an input device such as a keyboard 306, a pointing device suchas a mouse 308, a speaker 310 and a microphone 312. The speaker 310 andmicrophone 312 may be integrated into a handset 112 or headset, or maybe separate. The CPU 302 is connected to a network interface 108 asshown in FIG. 1.

FIG. 3 also illustrates an operating system (“OS”) 314 executed on theCPU 302. Running on top of the OS 314 is a software stack 316 for theclient 110. The software stack shows a protocol layer 322, a clientengine layer 320 and a client user interface layer (“UI”) 318. Eachlayer is responsible for specific functions. Because each layer usuallycommunicates with two other layers, they are regarded as being arrangedin a stack as shown in FIG. 3. The operating system 314 manages thehardware resources of the computer and handles data being transmitted toand from the network via the network interface 108. The client protocollayer 322 of the client software communicates with the operating system314 and manages the connections over the P2P system. Processes requiringhigher level processing are passed to the client engine layer 320. Inparticular, the client engine layer 320 comprises message managerfunctionality 324 and a message database 326. The functionality of theseelements will be described in more detail hereinafter. The client engine320 also communicates with the client user interface layer 318. Theclient engine 320 may be arranged to control the client user interfacelayer 318 to present information to the user via the user interface ofthe client (as shown in FIG. 2) and to receive information from the uservia the user interface. The control of the client user interface 318will be explained in more detail hereinafter.

As mentioned, the use of P2P client software permits the inclusion of alarge number of features that can be used by the users. However, thereis a difficultly in keeping the users informed of these features.Furthermore, it is useful for the P2P software provider to be able toinform the users of promotions that are available, and to give the usersfeedback in the case of detected problems or errors.

Error messages and information/help messages can be built into theclient (i.e. hard-coded) such that they can be shown to the users assoon as the client is installed and executed on the user's terminal.However, this has the significant disadvantage that the messages cannotbe adapted or changed without the user installing a new version of theclient. For example, the P2P software provider may become aware that aparticular feature is not being used frequently by the users, becausethe users are either unaware of its existence or do not understand howto use it. In such cases, hard-coded messages cannot change in order toinform the user of this feature. Similarly, the P2P software providermay begin offering a new promotion or pricing plan, which cannot becommunicated through the client until a new version is released with thehard-coded messages.

There is therefore a need for a dynamic message delivery system thatpermits the delivery of messages from the P2P software provider to theclients, such that these messages can be displayed by the clients toinform the users of pertinent information.

A dynamic message delivery system is shown illustrated in FIG. 1. Beforethe process by which the messages are delivered to the clients anddisplayed to the users is described, the process for creating themessages is outlined.

The messages are preferably created by an administrator affiliated withthe P2P software provider. However, in some embodiments, this role couldbe fullfilled by a trusted third party. Referring to FIG. 1, theadministrator 132 operates a user terminal 134 that is connected via anetwork interface 136 to a network 138 such as the Internet. Executed ona processor of the user terminal 134 is a web browser program 140. Theweb browser program 140 is used to view web pages retrieved over thenetwork 138 using the hypertext transfer protocol (“HTTP”). It will beunderstood that the network 106 used by the P2P system and the network138 used by the administrator 132 are both, in practice, the Internet.However, they are shown separately in FIG. 1 in order to distinguishbetween the information passed over the P2P system (network 106) and theinformation passed over the World Wide Web (network 138).

FIG. 4 shows a flowchart for the process by which the message is createdby the administrator 132. In step S402, the administrator executes theweb browser program 140 on the user terminal 134. In step S404, theadministrator 132 uses the web browser program 140 to log into a backoffice server (142 in FIG. 1) over the network 138. The back officeserver 142 displays to the administrator a selection of options thatdefine the structure, content and properties of the message. In S406,the administrator selects the options required options to define whatthe message should display and when it should be displayed. The detailsof the message structure will be described with reference to FIG. 5below.

Following the selection of the message options, in step S408, theadministrator selects to save the message. The message is saved by theback office server 142 in a content database (144 in FIG. 1). Themessage is marked as requiring review. The review is an optional stagewhereby the message is checked, e.g. for language. This may particularlybe needed if translations of the messages into multiple languages arerequired. In step S410 and S412 the process waits for the message to bereviewed. Once the message has been approved, then in step S414 themessage stored in the content DB 144 is marked as ready for publicationto the clients.

The messages that are created are grouped together into “bundles”.Bundles are created to minimise the amount of data that needs to betransmitted to the clients. Specifically, a bundle comprises the set ofmessages that are different to those messages that are pre-installedwith the client. Therefore, the bundle constitutes changes or additionsto the messages that the clients already contain. By creating thebundles, only those messages that are not already present in the clientare transmitted. Obviously, if only a single message is updated comparedto those already installed in the client, then the bundle will compriseonly one message. As different versions of the clients will containdifferent messages when they are installed on the user terminals,different bundles need to be compiled for different client versions.Each bundle is given a unique identifier in order to distinguish betweenthem. Once all the messages in a bundle have been approved, the bundleitself can be approved and can be marked as ready for publication to theclients

The process by which the messages are delivered to the clients isdescribed in detail with reference to FIG. 6 hereinafter.

Reference is now made to FIG. 5 which illustrates the detailed structureof the messages created by the above-described process and stored in thecontent DB 144. The message 500 comprises a message type field 502 whichdefines a particular category for the message. For example, the messagetype field 502 can define that the message is an information message, auser tip message or a promotion message. The type of message can be usedto determine how the message is displayed in the client, for examplebackground colours and icons can be displayed according to the type ofmessage. The message 500 also comprises a message content field 504,which contains the actual information to be displayed to the users ofthe clients. The message content 504 can comprise text, images,animation (e.g. flash animation) or a combination of the above. Examplemessage content will be described herein after.

The message 500 further comprises a trigger 506. The trigger 506 definesan event that must occur in the client before the message content isdisplayed to the user of the client. Example triggers include, but arenot limited to:

Making a call from a P2P client to another P2P client;

Making a call from a P2P client to the PSTN;

Receiving a call at a P2P client from another P2P client;

Receiving a call at a P2P client from the PSTN;

Starting to send a video feed;

Starting to receive a video feed;

Making a conference call;

A date, time or period (e.g. a specific date or every x days);

A missed call;

A contact is added to the user's contact list;

Viewing a particular UI in the client;

Starting an IM chat conversation with one party; and

Started an IM chat conversation with more than one party (called amultichat).

In addition to the trigger event 506 that must occur for the message tobe displayed, the message 500 can also define a condition 508 that mustfurther be satisfied in order for the message to be shown to the user.Example conditions include, but are not limited to:

The time elapsed since the message was last displayed;

The value of the user's account balance for outgoing PSTN calls;

The date of expiry of credit in the user's account for outgoing PSTNcalls;

Whether the user has subscribed to receive incoming PSTN calls;

The date of expiry of the user's incoming PSTN call subscription;

Whether the user has subscribed for voicemail;

The date of expiry of the user's voicemail subscription;

The user's region as defined in their profile;

A software registry key value;

The client version number for the user initiating a call;

The client version number for a user receiving a call;

The operating system on which the client is executed;

The user's privacy settings;

Has the user ever set a mood message;

The last date the user's avatar was changed;

Has the user ever had an IM chat conversation;

Has the user ever had an IM multi-chat conversation;

Has the user ever had a conference call;

Has the user ever used file transfer;

The number of contacts in the user's contact list;

Has the user set up call forwarding;

Has the user utilised a contact importing tool;

Has the user made a video call;

Has the user performed a video test;

Has the user made a PSTN call;

Is the other party in a call authorised by the user;

Is the other party in a call listed in the user's contact list;

The value of the audio gain level on the user's microphone;

The current call duration;

The currently viewed tab in the client UI;

The client's current CPU usage;

The current value of packet loss for a call;

The current roundtrip value for a call;

The currently available voice bandwidth;

The currently available video bandwidth;

Is the current call relayed over multiple peers;

The destination country of an outgoing PSTN call;

The originating country of an incoming PSTN call;

The amount of credit spent by the user today, this month, this year;

The language is the client in; and

The P2P identity (username) of the user.

Therefore, the trigger 506 defines the event that causes a particularcondition 508 to be checked. The condition 508 in the message defines avalue (e.g. a number, Boolean value or string) that must be checkedagainst a certain property within the client before the display of themessage can proceed. Furthermore, multiple conditions can be defined,such that more than one of the above-listed conditions must be met inorder for the message to be displayed. Optionally, no condition can beset, such that only the trigger 506 is required in order for the messageto be displayed.

The message 500 also comprises a link action field 510. The link action510 defines the action that is taken by the client when the user clickson a certain part of the message using the pointing device (e.g. acertain word, sequence of words or image). The link action 510 candefine that the client executes a web browser program, which navigatesto a certain webpage. Alternatively, the link action 510 can perform anaction within the client itself (e.g. opening an option window,displaying the user's profile etc).

A recycle field 512 is present in the message 500, which defines a setnumber of times that the message content 504 should be displayed. Evenif the message has triggered (506) and met the condition (508) it willonly be displayed if the number of times it has been displayedpreviously does not exceed the recycle value 512. Therefore, the recyclevalue 512 ensures that a given message will only be shown a certainnumber of times, thereby preventing it from becoming annoying for theusers. The recycle value 512 can also be set such that a message can bedisplayed an indefinite number of times.

The message 500 further comprises start and end date values 514. Thestart and end date values 514 define a time interval during which themessage should be displayed. This allows messages to only be displayedover a certain period, which is useful, for example, for time-sensitivemarketing campaigns. However, the values for the start and end dates canbe set such that the messages are always able to be displayed regardlessof the date.

The message 500 also comprises a display location 516 for the message inthe user interface of the client. Example display locations areillustrated in more detail with reference to FIGS. 8 to 12. Furthermore,the message 500 comprises a priority field 518. The priority field 518defines a priority level for the message in question, such that if theclient attempts to display two or more messages in the same location atthe same time, then only the message with the highest priority isdisplayed.

Therefore, at this point in the process a message has been created bythe administrator 132 (as illustrated with reference to FIG. 4)comprising the properties described above with reference to FIG. 5, andis stored in the content DB 144. Note that the administrator can createa plurality of messages, each of which is stored in the content DB 144.

The process by which the messages are delivered to the clients is nowdescribed with reference to FIG. 1 and FIG. 6. The clients (110, 122)are configured to periodically check whether new messages are availableto be downloaded. The message manager 324 (as illustrated in FIG. 3) isresponsible for triggering the periodic check for new messages. Theperiodicity of the message checking can be defined in order to balancethe requirements of rapidly delivering new messages against theconsequential network and server load. For example, the message checkingperiod can be every 14 days, although any time period may be used. Inorder to prevent all the clients in the P2P system simultaneouslyattempting to retrieve messages, each client independently maintains itsown timer of when messages were last retrieved. Therefore, as the usersinstall and execute clients at different times, this ensures that themessage retrieval is distributed over time, thereby reducing peaknetwork loading.

Referring to FIG. 6, in step S602 the client (110, 122) sends a “requestcontent” message via the network interface (108, 123) over the P2Psystem. The “request content” message contains an identifier of thebundle of messages currently held by the client, which allows themessage delivery system to determine which messages need to be providedto the client. The “request content” message also comprises the softwareversion number for the client and the operating system used on the userterminal. This information is provided because different bundles ofmessages are compiled for different operating systems and clientversions.

The “request content” message is transmitted from the client to a proxyserver 146 over the P2P system. The function of the proxy server 146 isto provide an interface between the peers of the P2P system and backendsystems. In particular, the proxy server 146 authenticates users of theP2P system to ensure that they are allowed to have access to the backendsystems.

Providing the client can be authenticated, the proxy server 146 forwardsthe “request content” message to a message server 148 in step S604. Themessage server 146 acts as the interface to the content DB 144, andhandles the delivery of messages to the clients. Multiple messageservers can be utilised in practice, in order to handle the load from alarge number of clients requesting content.

The message server 148 reads the information regarding the softwareversion, operating system and current message bundle ID from the“request content” message, and determines whether newer messages need tobe sent to the client. The message server 148 compares the bundle ID forthe most recent bundle for the given operating system and softwareversion to the bundle ID from the client. If a newer bundle of messagesexists then the message server prepares to send this to the client. Ifthe client already has the latest bundle (i.e. no existing messages havebeen changed or new ones added since either the client was installed orsince the last time the client requested messages from the messageserver) then the process stops without messages being transmitted to theclient.

Presuming that a newer bundle exists, the message server 148 requeststhe newer bundle from the content DB 144 in step S606, and in step S608the newer message bundle is returned to the message server 148. Notethat, in preferred embodiments, the message server 148 can also comprisea cache element 150, which is used to maintain a local cache of the mostrecent and commonly requested bundles. This can be advantageouslyutilised to avoid the need to fetch the bundle from the content DB 144,thereby reducing the load on the database.

In step S610, the message bundle is transmitted from the message server148 to the proxy server 146. The proxy server 146 then transmits themessage bundle to the client 110, 122 over the P2P system in step S612.The client then installs the message bundle. The new message bundle canadd new messages to the client, as well as make changes to existingmessages or delete messages. Once the message bundle is installed, thecurrent bundle ID held at the client is updated. The message bundle isreceived by the message manager 324 in the client and stored in themessage DB 326 in the client 110 as illustrated in FIG. 3.

In preferred embodiments, statistics about the messages displayed in theclients are also collected in step S614. For example, a set ofstatistics can be collected for each message, which include: a messageidentifier; the total number of times the message was displayed; thetotal number of times the user closed the message; the total number oftimes a link in the message is clicked on; and the total amount of time,in seconds, that the message was displayed. Different statisticsrequirements can be defined for different messages, and these statisticsrequirements can be pre-set in the installed client, or can becommunicated to the client along with the bundle of messages.

The statistics collected by the client are reported back to the messageserver 148 periodically by the client. For example, the client can bearranged to report statistics every four hours. When a time period haspassed such that the client needs to report statistics, then thestatistics are collated and transmitted in S616 to the proxy server 146,and forwarded to the message server 148 in S618. The message server 148then stores the statistics in the statistics DB 152 in step S620. Thesteps of S616 to S620 are repeated whenever the period for reportingstatistics expires.

Reference is now made to FIG. 7, which illustrates the process by whichmessages received at the client are interpreted and displayed. In stepS702, the client 110 is executed on the user terminal 104 of the user102. In step S704, the message manager 324 of the client 110 reads themessages stored in the message DB 326. In step S706, the message manager324 extracts the message properties from the messages, specificallythose properties described above with reference to FIG. 5, including thetrigger, conditions, recycle value, start and end dates and priority.The message manager 324 can then begin monitoring the client 110behaviour to determine whether to display the message.

In step S708, the message manager 324 starts monitoring the triggersdefined in the message. Example triggers were outlined hereinabove. If,in step S710, the event defined by the trigger has not yet occurred,then the message manager 324 continues monitoring in S708.Alternatively, if the trigger event has occurred, then in step S712 theconditions defined by the message are analysed. Example conditions weredescribed hereinbefore. Typically, the conditions define a value thatneeds to be compared against a property within the client. The messagemanager 324 performs this comparison to determine if the condition ismet. Note that multiple conditions may be defined in the message, whichmust all be met, or a null condition defined which is always met bydefault.

If the conditions are not met, then in step S714 the message manager 324ceases to process the current message in question, and returns tomonitoring triggers in step S708 for the display of future messages.Alternatively, if the conditions are met, then in step S716 the messagemanager 324 checks the number of times that the message in question hasbeen displayed. If it is found in step S718 that this exceeds therecycle value for this message, then the message is not displayed, andthe message manager returns to monitoring triggers in step S708. If,however, step S718 finds that the recycle value has not been exceeded,then the process proceeds to step S720.

In step S720, the message manager 324 checks the start and end datevalues for this message. As mentioned before, these values define a timeinterval during which the message should be displayed. Therefore, instep S720, the message manager compares the current date to the startand end dates, to determine if the current date falls within them. If instep S722 the current date is not within the start and end dates, thenthe message display should be skipped and the message manager 324returns to monitoring the triggers in step S708.

If the message is to be displayed (i.e. the current date is within thestart and end dates), then in step S724 it is checked whether anothermessage is already displayed at this display location, and if so, thepriority levels of the message are compared. In step S726, if thepriority level of the current message is lower than another messagealready being displayed, then the current message is not displayed andstep S708 is returned to. However, if another message is not beingdisplayed at the display location, or the current message has a higherpriority, then in step S726 the message display is not skipped, and inthe step S728 the message is displayed in the UI of the client 110. Moredetails on the display of the message in the client is provided withreference to FIGS. 8 to 13 below. Finally, in step S730, the count ofthe number of times the message in question has been displayed isincremented, before the message manager 324 returns to monitoring thetriggers in step S708.

The above process is obviously performed for every message that isstored in the bundles in the message DB 326. It should also be notedthat the monitoring, triggering and display of messages happens inparallel for all messages in the client. Therefore, more than onemessage can be triggered and displayed in the client at one time.

Reference is now made to FIGS. 8 to 12, which illustrates examplelocations where the messages can be displayed in the client 110. Asmentioned with regards to FIG. 5, the messages define a UI displaylocation (516) which determines where the message is displayed.

FIG. 8 shows the user interface of the client 110 when displaying thecontact list tab 206, as described above with reference to FIG. 2.However, in the case of FIG. 8, there is a placeholder 802 for a messageto be displayed below the contact list. The message placeholder 802comprises a close button 804 that removes the message from the display,thereby reverting the client to the form shown in FIG. 2.

FIG. 9 shows the UI of the client 110 when the tab named “call phones”902 is selected. This tab 902 displays a keypad 904, allowing the userto enter a telephone number to call. This tab 902 shows an examplemessage display location 906 with a close button 908 as described above.FIG. 10 shows the UI of the client when the tab labelled “live” 1002 isselected. This tab 1002 displays a list 1004 of ongoing and upcomingpublic conversations that can be joined by the user. This tab 1002 alsodisplays an example message location 1006 with a close button 1008.

FIG. 11 illustrates the UI of the client 110 when the tab labelled“SkypeFind” 1102 is selected by the user. This tab 1102 displays adirectory service with fields 1104 for searching for businesses. Thistab 1102 displays an example message location 1106 with a close button1108. FIG. 12 shows the tab displayed to the user of the client 110 whena call is in progress. In this case, User A 102 is in a call with UserB114. The call tab 1202 displays information 1204 about the user beingcalled. An example message location 1206 with a close button 1208 isshown at the bottom of the tab.

Reference is now made to FIG. 13, which illustrates a set of examplemessages that can be displayed in the UI locations described previously.

Message 1302 is a message displayed in the call tab 1202 as shown inFIG. 12. This message indicates to the user that the client 110 cannotdetect any sound on the microphone, and hence there may be a problemwith the audio settings. The trigger for this message is making a call(of any type), and the condition is the audio gain level on themicrophone. The link in the message (i.e. the link action 510 from FIG.5) takes the user to the audio settings of the client 110 (i.e. alocation internal to the client).

Message 1304 is a message displayed in the contacts tab 206 shown inFIG. 8. The message prompts the user to sign up for a voicemail service.The trigger for this message is a missed call at the client, and thecondition is that user has not subscribed to voicemail. The link takesthe user to an internet page where they can subscribe to the voicemailservice.

Message 1306 is a message displayed in the call phones tab 902 shown inFIG. 9. This message informs the user that they need to purchase creditin order to make calls to the PSTN network. The trigger is the userviewing the call phones tab 902, and the condition is the user's creditbalance is zero. The link action takes the user to an internet pagewhere they can purchase credit.

Message 1308 is a promotional message displayed in the contacts list tab206 shown in FIG. 8. This message promotes a service whereby the usercan purchase a telephone number to allow PSTN users to call their VoIPclient. The trigger for this message is time-based, such that it isdisplayed on a specified number of days. The condition is that the userhas not already signed up for this service—it is not desirable topromote a service the user already has. The link takes the user to aninternet page where they can subscribe to the service.

Message 1310 is a message displayed in the call tab 1202 shown in FIG.12. If the user was making a PSTN call (trigger) and the balance of hisaccount goes to zero (condition) then the message is displayed. Thelinks display webpages for the user to buy more credit and to set up anautomatic credit recharging system.

Message 1312 is a promotional message displayed in the live 1002 orSkypeFind 1102 tabs in FIG. 10 or 11 respectively. This message includesimages as well as text. The message promotes a subscription service. Thetrigger is time-based, and the condition is that the user has notalready subscribed to the service. The link displays a webpage in whichthe user can subscribe to the service.

Message 1314 is displayed in the call tab 1202. The trigger is that theuser is making a call to a PSTN number. There is no condition applied tothis message. The message notifies the user that the call would be freeif the other party also used the VoIP service, and the link takes theuser to a webpage where the user can invite the other party to join theVoIP service.

Therefore, as shown with the examples above, the messages displayed inthe client are relevant to the particular user of the client, due tousing triggers and conditions that are dependent upon actions occurringwithin the client itself.

While this invention has been particularly shown and described withreferences to example embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

We claim:
 1. A method comprising: receiving a message by a communicationclient, the message comprising a trigger event that is to occur for acondition to be checked, the condition comprising a parameter value forevaluating whether the condition has been satisfied; monitoring a userterminal subsequent to receiving the message to determine whether thetrigger event occurs at the user terminal; determining whether thecondition has been satisfied at the user terminal in response to adetermination that the trigger event occurred; displaying a selectableoption for reconfiguring an attribute of the communication client inresponse to a determination that the condition has been satisfied; andreconfiguring the attribute of the communication client in response to aselection of the selectable option.
 2. The method according to claim 1further comprising reading a current value of a parameter in the userterminal and comparing the current value to the parameter value of thecondition.
 3. The method according to claim 2, wherein the parametervalue defines a maximum number of times the message is to be displayedby the communication client.
 4. The method according to claim 2, whereinthe parameter value defines a start time and an end time for displayingthe message.
 5. The method according to claim 1, further comprisingtransmitting, prior to the receiving, a request for the message over acommunication network.
 6. The method according to claim 5, wherein therequest for the message comprises an identifier of a plurality ofmessages stored at the user terminal.
 7. The method according to claim5, wherein the request for messages comprises at least one of a versionnumber for a communication client executed on time user terminal and anidentifier of an operating system executed on the user terminal.
 8. Themethod according to claim 1, wherein the message is received at the userterminal in a bundle comprising a plurality of messages.
 9. The methodaccording to claim 1, further comprising: displaying a selectablecontrol configured to cause display of information included with themessage.
 10. The method according to claim 9, wherein the selectablecontrol is a hyperlink comprising a network address of the information.11. A system comprising: one or more processors; and one or morecomputer-readable storage devices having computer-executableinstructions stored thereon that, when executed by the one or moreprocessors, configure a user terminal to perform a plurality ofoperations comprising: receiving a message by a communication client,the message comprising a trigger event that is to occur for a conditionto be checked, the condition comprising a parameter value for evaluatingwhether the condition has been satisfied; monitoring the user terminalsubsequent to receiving the message to determine whether the triggerevent occurs at the user terminal; determining whether the condition hasbeen satisfied at the user terminal in response to a determination thatthe trigger event occurred; displaying a selectable option forreconfiguring an attribute of the communication client in response to adetermination that the condition has been satisfied; and reconfiguringthe attribute of the communication client in response to a selection ofthe selectable option.
 12. The system according to claim 11, wherein theplurality of operations further comprises reading a current value of aparameter in the user terminal and comparing the current value to theparameter value of the condition.
 13. The system according to claim 12,wherein the parameter value defines a maximum number of times themessage is to be displayed by the communication client.
 14. The systemaccording to claim 12, wherein the parameter value defines a start timeand an end time for displaying the message.
 15. The system according toclaim 11, wherein the plurality of operations further comprisestransmitting, prior to the receiving, a request for the message over acommunication network.
 16. The system according to claim 15, wherein therequest for the message comprises an identifier of a plurality ofmessages stored at the user terminal.
 17. The system according to claim15, wherein the request for messages comprises at least one of a versionnumber for a communication client executed on the user terminal and anidentifier of an operating system executed on the user terminal.
 18. Thesystem according to claim 11, wherein the message is received at theuser terminal in a bundle comprising a plurality of messages.
 19. Thesystem according to claim 11, wherein the plurality of operationsfurther comprises: displaying a selectable control configured to causedisplay of information included with the message.
 20. The systemaccording to claim 19, wherein the selectable control is a hyperlinkcomprising a network address of the information.